Repository navigation
Conversation
|
any update ? |
akx
left a comment
akx
left a comment
There was a problem hiding this comment.
Thank you for the PR, but I'm not sure it's necessary or complete.
- Did you try this with the current Babel data?
- Can you construct a scenario where
def load()can load an arbitrary attacker-constructed pickle, or how an attacker could modify a pickle in the data directory to be malicious (without having permissions to similarly modifybabel/localedata.py)?
|
It doesn't hold up on either point. Current data. The PR only tested hand-built pickles, not the shipped files. Against a fresh CLDR 47 import it breaks:
The allow-list is missing Scenario. I can't construct one. Tradeoff. A corrected allow-list would have to track whatever |
2 participants
this replaces the direct pickle.load() usage in babel.localedata with a restricted unpickler.
right now locale data files are loaded using pickle without restricting what objects can be created during deserialization. this change adds a _SafeUnpickler which only allows the small set of classes and builtin types that babel actually needs for locale data loading.
also added security tests to make sure:
normal locale data still loads correctly
malicious pickle payloads are rejected
unsafe globals cannot be loaded during deserialization
the existing
.datfiles continue to work and no changes are needed for the locale generation process.this is mainly a defense in depth hardening change to make locale data loading safer against malicious or corrupted pickle data.